NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/8431

Internet Message Format | 1996-08-05 | 6.8 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c
Subject: Re: What is &Variable (declared as: char Variable[10])?
Date: 3 Mar 1996 21:36:09 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <4gqpa1$[e-mail]> <4hagqg$[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <4hagqg$[e-mail]>,
Reginald W. Sprecher <[e-mail]> wrote:
 >I am sure that many of you will protest about what I am about to say
 >about pointers but it is my intention to try and clarify what all the
 >fuss is about.
 >
 >First off we need to start with some definitions.
 >
 >1.  A pointer - a pointer is a variable which has as its purpose the
 >ability to point to another variable.  One thing that needs to be made
 >clear here is that the size of a pointer is always the same no matter
 >what type of data the pointer is pointing at ( a pointer to a char and
 >an int are the same size). However, this is not and will not hold

This is false. Read the FAQ about some unusual computer architectures which
have been used as C targets.

 >across machines.  For example, a pointer on an pc-xt type computer
 >would be different from a pentium computer.  This is because the

You are botching up your definition of a pointer with secondary issues. :)
If you said this to a class, it would distract from the lecture about pointers.

 >pointer needs to be able to hold an address to something.  If the
 >memory space in a target machine is 16 bits then a pointer for that
 >machine is 16 bits.  If the memory space on a different machine is 32
 >bits then the size of the pointer is 32 bits.
 >
 >2. address - all variables, including pointers and arrays, have a
 >address as to where they live in memory.

Even variables declared 'register'? Gotcha. Gotta be careful around here,
it's shark territory! :) What about bit-field variables? Gotcha twice.

 >3. & - the & is the 'give me the address where the indicated variable
 >lives in memory' command.  All variables live in memory and therefore
 >have an address.  This address can only be resolved at runtime.

False. Static addresses can be nicely resolved at link time, or even compile
time depending on the environment.

 >Now lets walk through a small program.  (assume for this discussion
 >that we are running on a 16 bit machine, aka pc-xt.

Snore...

 >void main(void)

Slap on the wrist for void main() from me. Noose around your neck from some
other regulars of c.l.c. Fix that to int main()!

 >{
 >
 >  int a;
 >  int b[3];
 >  char c[4];
 >  char  *a_pointer;
 >
 >  a = sizeof(b);
 >  a = sizeof(c);
 >
 >  a_pointer = c;       // or a_pointer = &c[0]

Syntax error on token //

 >  scanf("%s",c);
 >
 >}
 >
 >1.  The first four statement instructs our program to create memory
 >for the indicated variables on the stack.  After these instructions

Yes, a conceptual stack.

 >are performed our memory looks like:
 >
 >                       address     (our name)
 >________
 >|                |     1000        a  (because a is an int we need 2 bytes to store it)
 >|                |     1001
 >-------------
 >|                |     1002        b[0]  this is the first element of array b

Are you sure that the C language calls for this kind of layout? This is great
from a hacker's point of view, but reveals little about the C language.

 >2.  The next thing we encounter is the sizeof instructions.  Be
 >carefull here, sizeof looks like a C runtime function, acts like a C
 >runtime function but is not a C runtime function.  It is really some

False! It only looks like a ``runtime function'' (whatever that is) if you
insist on writing parentheses around its argument.

It is an operator, something that is clear if you do this:

    char x[3];

    int s = sizeof x; /* don't look like no runtime function ta me! */

 >instructions to tell the compiler to calculate the size of the
 >indicated variable at compile time and not at runtime.  It is because

False. Sizeof also takes parenthesized type expressions and computes their
size. These are clearly not variable names or lvalues of any sort.

 >The crux of the problem.
 >
 >Is the name of an array a pointer?  The answer to this, using our
 >definition of what a pointer is, is no.  The name of an array is not a

Right. No.

 >pointer, but it is what we would call an address.  This is because we

Wrong. It is a symbol which refers to an object. An address is but one of the
many attributes that the symbol may have.

Fact: the address of an array can change. Automatic arrays will likely have a
different address each time you invoke the function, and certainly so if you do
it recursively. Yet, the name of the array is no longer available at run-time,
so there can be no possible symbol-table association between the name and the
vast multitude of possible addresses it can have.

I think you are confusing assembly language labels with C arrays.

 >define all arrays in terms of where they begin in memory.  Therefore
 >the following expressions are equal
 >
 >          c == &c[0]
 >(1008) == (1008)  ----> from our memory map
 >
 >This fact therefore makes it possible to intermix the following array
 >notation:
 >
 >c[1]  or *(c + 1)

There is no logical implication here. The only ``therefore'' that is valid is
one that is backed by a reading of the grammar as given in the C standard. The
notation can be intermixed because the designers of the C languages decreed it
so, and for no other reason!!!

 >Missconcepetions:
 >
 >
 >1)  Using the name of an array somehow yields or calculates or
 >generates the address.
 >
 >This is not true. The name of the array is the address of the array.
 >The operation is not a calculation or de-referencing, or ....

It is a conceptual calculation performed in the syntax directed translation of
the program. The type expression (char (*)[]) calculates a type. That it's done
in the compiler is irrelevant.

What makes you sure that the address of an array is not computed? If your array
is known as a stack-frame offset, sure as hell you have to calculate it. The
machine code has to compute the effective address by adding the displacement to
the value of the stack pointer (on a machine that has this sort of familiar
layout).

 >I have personally never heard of this 'decay' process.  If you look

The decay process is a real fact of C, even though it may not be evident from a
translation to a particular machine architecture. Some people find the name
misleading, however, because it can lead beginners into believing that an
actual object is being transformed via some sort of decay process.

 >3)  Pointer take on different sizes.

 >Pointers only take on a different size when going from one platform to
 >another.  If you write a program and define 1000 pointers that can

You have not read the FAQ, have you?
--